In recent years, the Internet has become one of the most important tools for organizations to communicate and interact with each other. For security reasons, a user in a particular organization often has to be authenticated before being granted access to resources in another organization. Different mechanisms have been developed to facilitate user authentication. One such mechanism is Web Services (WS)-Federation. WS-Federation enables the sharing of identity across enterprise boundaries using Extensible Markup Language (XML) security tokens. These XML tokens utilize formats, such as Security Assertion Markup Language (SAML) or Extensible Rights Markup Language (XrML), and contain rich authorization claims in addition to identity data. For example, under WS-Federation, a security token associated with an account may assert not just the account's identity (e.g. in the form of an email address) but also date of birth, group affiliations, or the like.
Typically, the claims in the security tokens flow between a pair of enterprises. The originator of the tokens is called the Identity Provider. The Identity Provider owns a user's identity and authentication. The consumer of the tokens is called the Resource Provider. The Resource Provider may provide any number of Web Services or other applications. A cryptographic trust may be established between the two parties (for example, the Identity Provider shares his X509 certificate with the Resource Provider) so that the Resource Provider can authenticate the Identity Provider as the authority for security tokens.
In WS-Federation, the Identity Provider typically deploys a server that hosts a Security Token Service (STS). An Identity Provider's STS is generally referred to as STS-IP. The STS-IP authenticates users based on legacy credentials (e.g. username and password) and issues a WS-Federation security token, which will be accepted by the Resource Provider.
Under WS-Federation, it is possible for web services or other applications to have explicit trust with each partner's STS-IP. However, in order to simplify the administration of trust, the Resource Provider generally deploys its own STS, which may be referred to as STS-RP. Individual applications typically trust the STS-RP and a single trust generally exists between STS-RP-and STS-IP, which embodies the business level agreement between the two parties. In this manner, each application may be ignorant of the many different Identity Providers.
Although WS-Federation is an effective way to establish trust between two systems, the relationships may become difficult to manage when the systems increase in complexity. Specifically, if a Resource Provider deploys multiple applications, these applications may not all expect security claims in the same format. For example, one application may expect the user's date of birth while another may expect the user's age. Similarly, difficulties may arise if each partner Identity Provider provides claims in different incompatible formats. For this reason, it is often necessary for the STS-RP to perform transformation from the claim format of an Identity Provider to the claim format required by an application.
The conventional way of performing claim transformation involves defining a different claim transformation for each pair of Identity Provider and application. This approach can result in exponential growth of the number of transformation rules relative to the number of Identity Providers and applications. For example, a Resource Provider with 10 trusted Identity Providers and 10 applications would have 100 different claim transformations to define and maintain. The addition of another Identity Provider would necessitate the creation of 10 additional claim transformation rules. This behavior results in considerable complexity for a large scale WS-Federation system.
An effective solution for handling claim transformation without undue complexity continues to elude those skilled in the art.
Like reference numerals are used to designate like parts in the accompanying drawings.